Recent advances in digital technology have led to impressive new devices, such as Digital Versatile Disk (DVD) players, Digital TVs, and PCs which are capable of playing movies. However, at the same time these gains have lead to increasing concerns regarding the transmission of copy-protected material between such devices. In particular, the unauthorized copying, intercepting, and tampering of audio and video content presents concerns. The specification entitled, ‘The Digital Transmission Content Protection (DTCP) Specification’ (developed by The Digital Transmission Licensing Administrator) defines a protocol for protecting against such concerns using cryptography.
In the conventional method described in the DTCP specification, when a receiving (sink) device wishes to receive a digital audio/video signal from a sending (source) device, the sink device must first be authenticated. After a device is authenticated, an encryption key is exchanged between the source and the sink device. This key is used to encrypt the signal at the source and decrypt the signal at the sink.
One conventional way to authenticate a device is for the source device to determine whether the sink device is compliant with a copy-protection protocol. In the conventional protocol defined in the DTCP specification, each compliant device is given a certificate, which the device stores and uses in the authentication process. For example, a source device, such as a television set-top box may wish to determine whether a receiving sink device, such as a DVD player or a VCR, complies with a copy protection protocol and hence warrants having copy-protected material sent to it.
Importantly, the conventional system described in the DTCP specification requires that the source and sink devices have the ability to send and receive packets of information of at least 32 bytes. As the certificates used in authentication are generally larger than this, the packets will generally be fragmented for transfer and de-fragmented upon reception. Sending and receiving these fragmented packets (e.g., AV/C commands and responses, as well as data such as certificates) complicates the programming when done conventionally.
One conventional method of implementing packet fragmentation and de-fragmentation is a state machine which moves through various states as the method proceeds. There may be a different set of states depending upon factors such as whether full or restricted authentication is being sought by a device. (For example, if the audio/video signal is to never be copied, the sink device may request full authentication. If the signal is copy-one-generation or no-more-copies, the sink may request either full or restricted authentication.) Sending and receiving fragmented packets only complicates the programming of the state machine. For a conventional method which integrates the function of sending and receiving packets of information into the authentication software, designing and testing the sending and receiving software is complex.
To simplify programming the devices, many software engineers fix the size of the packets which the device may send or receive. However, this can lead to performance problems. When two devices wish to exchange information, first they must determine the size of packets each is capable of exchanging. If one device has a fixed transfer size, naturally the other device will be limited to this size. Furthermore, in the future, the minimum size of packets which a device must be capable of transferring may be increased. Therefore, some conventional devices will fail to comply with the DTCP specification, and hence may be unable to operate with other devices.